Internet Protocol capable audio communication devices, whether they are wired or wireless, that format packets of audio information according to the RTP protocol for transmission to another audio communications device include, among other things, in the header field of each packet a timestamp value that represents a time reference when the packet is created. This time reference can be, for instance, based on the number of audio samples that have been generated during a communication session to that point. So, for instance, if the first packet of audio information transmitted during a communications session has a timestamp value of “Zero” and if there were eighty samples of audio information in each packet, the next packet transmitted would have a time stamp value of eighty, and so forth. Alternatively, the timestamp value could represent a synchronized network clock value at the point in time that the first sample in each frame was generated. Regardless of the strategy used to create the timestamp, this value is used by an audio communications device that receives the packet to determine the current mean transmission delay time, the level of jitter that is being experienced, the order in which each packet is selected for processing and the time at which the packet should be “played” by the communications device. Under certain circumstances, a communications device that is generating packets of audio information may mark one or more of the packets with incorrect timestamp values. This can happen for a variety of reasons. For instance, if a communications device marks a packet with a timestamp value at the time the packet is transmitted as opposed to the time the packet was generated, normal variations in transmission delay would result in incorrect timestamp values.
As a consequence of the above, if the communications device is configured to process a packet containing two hundred forty samples of audio information and receives packets with timestamp values are not valid, the devices may try to play the packet at the wrong time or ignore the packet entirely. This has the effect of creating periods of silence or the loss of voice information during a communication session. So, for instance, if a current packet has a timestamp value of “4528” and a subsequent packet has a timestamp value of “4757”, it is likely that the communications device would drop the first eleven samples of the subsequent packet therefore losing the audio information contained in those eleven samples. On the other hand, if the communications device detects a timestamp value of “4510” in a current packet and a value of “4757” in a subsequent packet, there would be missing information between packets equivalent to the time it takes to play seven samples. This gap may be perceived by the user as sharp clicking sounds, stuttering or periods of silence. Generally speaking, the behavior of a communications device to packets it perceives as arriving early or late has a damaging effect on the overall quality of a communications session.
So, it would be advantageous if a communications device was capable of processing incorrectly timestamped packets of audio information as if the packets were correctly timestamped. Further, the quality of a communications session would be improved if entire or portions of incorrectly timestamped packets were not discarded by the receiving communications device. I have solved this problem by inventing a method that enables a wired or wireless communications device to maintain a high quality communications session in the presence of incorrectly timestamped packets of audio information by modifying the timestamps of incoming packets, if they deviate by no more than a specified amount, so that the timestamp value coincides with a calculated, known good timestamp value.